| Garbage Collection > Class Helpers > Contents |
|
The
.NET Framework is a rich hierarchy of classes and types. It contains a myriad
of functionality, from collection classes, to string manipulation, to network
communication, and a whole host of others. Borland's own VCL is also a rich
framework, offering an equally wide range of functionality. The .NET Framework
and the VCL framework are two class hierarchies with a similar goal: to relieve
the programmer from having to re-implement commonly used patterns, algorithms,
and utilities.
The
migration of the VCL to the .NET platform has revealed that the two frameworks
have much in common besides a similar design goal. The .NET Framework contains
functionality that has been present in the VCL for years. So much so, that at
first glance the .NET Framework might look like a complete replacement for the
VCL. Indeed, one significant goal of the VCL migration is to leverage as much
of the .NET Framework as possible. But merely replacing the VCL with the .NET
Framework would not provide a suitable migration path for existing VCL users.
The
.NET and VCL frameworks complement each other. A better migration
solution is to allow VCL users to adapt .NET Framework classes -- create
equivalent VCL classes -- and then add functionality expected by existing
Delphi code, but not provided by .NET. The language feature that allows this
form of extension is called a class helper.
A
class helper is not a form of derivation; it does not introduce a new class
type as such. A class helper introduces a new, wider scope for the compiler to
use when resolving identifiers. When you declare a class helper, you state the
helper name, and the name of the class you are going to extend with the helper.
You can use the class helper any place where you can legally use the extended
class. The compiler's resolution scope then becomes the original class, plus
the class helper. To reiterate: a class helper is not a form of derivation. It
is an alias for another class.
A
good example of class helpers is the .NET class System.Object, and the VCL
class TObject. In Delphi for .NET, TObject is not derived from System.Object,
it is a helper for System.Object. The TObject helper introduces methods such as
ClassName, and ClassType. This allows the .NET class to be used with existing
Delphi code, which expects these methods. This would not be possible using the
traditional technique of derivation.
Class
helpers provide a way to extend a class, but they should not be viewed as a
design tool to be used when developing new code. They should be used solely for
their intended purpose, which is to adapt .NET classes to existing Delphi code.
Component writers, who might be porting a Delphi component to the .NET
Framework, will most likely encounter this scenario.
When
porting a component, a developer might find a class in the .NET Framework that
is very similar, but not exactly equivalent to the Delphi component. This is a
case for using a class helper for the .NET Framework class, and then using the
helper to extend that class with properties and methods in the Delphi
component, but not in the .NET class. The result is a new Delphi component that
will gain the benefits of the .NET platform, and, continue to run with existing
code.
The
syntax for declaring a class helper is:
ClassHelper = class helper [(ancestor
list)] for type-id
end;
A
class helper is typically introduced with a type declaration:
type
TMyClass
= Some.VerySimilar.Class;
Then
you declare the class helper:
// Introduce the class helper and declare
the function expected
// by existing Delphi code.
TMyClassHelper = class helper for TMyClass
function
ExistingDelphiFunc : Integer;
end;
Now,
your existing Delphi code, which is expecting the type TMyClass to have a
function called ExistingDelphiFunc, will continue to run. The bulk of
functionality provided by TMyClass is now implemented in the original class
(Some.VerySimilar.Class), and the compatibility code is implemented in the
helper class.
Class
helpers may introduce both class methods, and instance methods. For instance
methods, the Self pointer is always the type of the extended class, not the
class helper. In the example, the Self pointer would refer to TMyClass. Class
helpers do not introduce a new type. Further, you will never create an instance
of a class helper in your source code.
You
can only create one class helper for a given class. However, when you declare
the class helper, you can specify an ancestor list, which allows you to inherit
functionality from other class helpers.
| Top | Contents | Copyrights | Borland Developer Network | Borland Home |